Serverless Framework Hands On
参考
事前準備
Cloud9（みんなと環境を合わせるため）のみ
https://gyazo.com/e53a13b5c6e9d39c41585ab61da28be3 https://docs.google.com/presentation/d/1P0cLuIKjPcSJ2TBisQVCypH5JHUJwJVsBEZPCx5cWIE/edit#slide=id.gb83e38e90d_0_504
ジンを招待する
cloud9環境を作る
Cloud9からSlack通知やってみる。すぐできる。
定型文が嫌だから、編集してみる。
変数設定できるようにする。
テキストをSlackで受け取れるようにする。
Slack Appを作ろう
Slackから受け取るためには受け取るための仕組みが必要。API Gatewayを作る。
「上手に受け取れたよ」だけをAPI Gatewayで結果返却できるようになろう
API Gatewayで受け取ったテキストを使って処理できるようにしたい
Lambdaを作って、API Gatewayから受けとる。
Requestsが使えない…！？Lambdaああああ
ここらへんで限界が来るのでsls deployを解禁。lambdaがこんなに簡単に作れるなんて。
合わせてAPI Gatewayもserverlessで管理しよう
code増えてきたからgitで管理しよう
「受け取って、返して」ができるようになった。ここで一気にセキュリティを強めたいぞ
IAMを設定。最小権限の法則だ（これは理由付きで説明しないとダメ）
最後、Githubにupload……する前に
secrets、gitにindexされちゃってますよねwwwwこのままだとsecurity holeです。
じゃあ、どうやったらよかったんだろうか…？codeに直書きしないstyleにしましょう
secrets managerの出番です。
localとlambdaで設定を切り分けよう
設定を分けるために、実行環境が何なのか？をosから判断しよう。
まだ入っていない要素
共同開発（Pull Request）
production開発（CI/CD）
lambdaのtest頻度を上げるためにdocker
Gitちゃんと使いこなす
計算量をcheckする作業をやってみせる動画
リファクタリングする動画
事前用意するもの
AWStsawada.icon
クレカ紐づいたAWSを準備しておく
以下二つは速攻で作って、jsakumaにもprofile設定しておいてもらう
Scrapboxtsawada.icon
Slack Workspacetsawada.icon
ないと検証できねえ…
悩みポイント
「テスト駆動開発」「Git」「CI/CD」を最初から本気で入れるか？
必要になったら（検証が困難になってきたら、コード量が増えてきたら）にしよう
言い続けるのが「やったことがうまくいったか検証できないの不安！」はペアプロで言い続けるやつ
出てくるAWS serviceの説明を逐一するか？
でてくる
Cloud9
API Gateway
Lambda
IAM
説明の仕方色々ある
呪文として説明する。
「なぜ近しい他のサービスではなくこれを使うのか」を説明する
悩みポイント
secretsはcodeに直書きしますか…w？tsawada.icon
Slack Appの作成で「manifest」使う…？tsawada.icon
どんなapplication作る？
eventはslack channelの生成。生成されたslack channelを通知する
----------------------------------------------------------------------------------------------------------------------------
今回で勉強できること
作るもの
「電話帳」
ざっくりの流れ
前提説明
最後はAWSで動く。でも最初からAWS(というかブラウザ)で開発するの？
動くもの見ながら作業が一つずつ反映されていくほうが目に見えて楽しいよね
一気に変えると一気にエラーがくる。しんどい！原因がわからなくなる！少しずつ…少しずつ変えましょう。
1.iconLambdaがマネコンでテストできるようになるまで
Todo done.icon最初の環境構築
node, serverlessのinstall
Todo done.iconまずはLambdaの作成
mkdirでfolderの作成
serverless.ymlの作成
code:yml
provider:
lambdaHashingVersion: 20201221
function.jsの作成
sls deploy
Lambda動く！
2.iconEndpoint URL経由でテストができるようになるまで
Todo done.icon毎回Lambdaの画面いくの…しんどいよね。じゃあ外からaccessできるようにしよう
serverless.ymlの修正
sls deploy
terminal.iconからcurl で実行してみるぞい。うまくいかない
API Gatewayのマネコンでチェック！502 Errorに対応。あ、API Gatewayが許してくれる形があるらしい
形に合わせたぞ。curlがうまくいった
3.icon内部品質向上①）バージョン管理
Todo done.iconうまくいかなくなった時に、戻すの大変だよね。git管理しましょう
git init
README.mdの作成
Todo done.iconみんなでreviewしたりコード書いたりしたいよね。みんなが触れるところに上げておきましょう
aws credentialの設定
CodeCommitへPush
3.icon内部品質向上②）CI/CD
Todo done.iconちょっと大きくなってきた。deploy頻度も上がってきて大変だしCD/CIとやらを作ってみよう
マネコンでCodeBuildを作ってみる
マネコンでCodePipelineを作ってみる
「自動連携」されるようになったことをREADME.mdに記載しよう
buildspec.ymlにCodeBuildで実行して欲しいことをMUSTしてみよう
git push
勝手にdeployされる！
が、CodeBuildに権限がないって言われる
4.icon内部品質向上③）細かいテスト実施環境の構築
todo_done.iconうーむ。一回ごとにかかる手間が増えてきたぞ。これは辛い。よし「もっと簡単にチェックできる状況」を作ろう
power-assertとmochaの準備
testを手元で実行してみる。
javascriptの別ファイル読み込みだ
超便利！手元でチョコチョコ検証できるようになったぞ
5.icon機能追加①）簡単なファイルを使って「複数dataの使い分け」ができるように
もっと複雑にデータを返すようにしたいぞ。例えば名前とメルアドの対応を。
csvを生成。
table:data
name telephone_number
A 0123-456-789
B 0987-654-321
csvを読み込めるようにjavascriptを修正
修正したjavascriptでpower-assert。よし期待通り動いたぞ
git push！勝手にdeploy
6.icon機能追加②）簡単なファイルを使って「複数dataの出しわけ」をできるように
よし。今度は書き込み/読み込み両方ができるようにしたいな
csvだと不十分。よしDMBSを使うぞ
（ここは設計図で書いてみせる）
書き込み読み込みが急に集中してもごちゃごちゃにならないようにしたいね。
DMBSでよく使うものとして今回はDynamoDB使ってみよう
管理はしんどいけど「読み書きをちゃんとする」のならこれで超十分
DynamoDBを使えるようにserverless.ymlに追記
Hashだけ。Rangeは作らないように
IAM Statementsも記載する
DynamoDBを使うようにfunction.jsも修正
git push！
7.icon内部品質向上④）dockerの導入
ここで気付く。一気にcodeのtestがしにくくなったなって。
まずはlocalでもDynamoDB使えるようにしよう
擬似的にDynamoDBをlocalでも実行しなきゃ。そうだdocker！
docker-compose.ymlの作成。使ってみる。うまくいった
8.icon内部品質向上⑤）mockの導入
docekr-compose.yml使わなくてもいいくらい小さいのも欲しい。
そうここでMock